「幫我寫一套連續 30 天的鐵人賽文章。」

這句話看起來已經很完整：有產出形式、有篇數，甚至還帶著每天都得交稿的壓力。要是再補一個題目，好像就可以按下生成鍵，等 AI 把 30 篇文章排隊吐出來。

但我不能只靠這句話，判斷一套系列應該怎麼寫。

問題不是它少了幾個漂亮的提示詞，也不是 AI 一定寫不出單篇文章。真正的問題是：這句話描述了我要多少東西，卻沒有說清楚這 30 篇要共同完成什麼。

數量不是系列設計

30 篇文章可以只是 30 個同主題的檔案，也可以是一條逐步推進的閱讀路徑。兩者的數量相同，讀者得到的東西卻完全不同。

如果我要的是一套系列，至少還有以下決策不能留給模型自行猜測。

第一，讀者是誰，讀完後要發生什麼改變？「介紹 Agent Skill」可以寫給第一次聽到這個名詞的人，也可以寫給正在設計 Skill 的工程師。前者需要先建立問題意識，後者可能更在意資料契約、測試與失敗處理。沒有讀者與結果，內容深淺就只是碰運氣。

第二，30 天如何分工？每篇都要有自己的問題與新價值，還要知道哪些概念已經說過、哪些結論尚未輪到它。否則，Day 3 可能重講 Day 1，Day 7 先洩漏 Day 20 的結論，最後一天只剩下替前文重新包裝。

第三，事實要靠什麼支持？專案文件、實際執行結果、外部資料、作者經驗與模型推論不是同一種證據。若不先決定來源與查證規則，一段合理的文字很容易把「可能如此」寫成「已經證明如此」。

第四，文章應該有什麼聲音與限制？語言、篇幅、技術深度、幽默程度、禁用格式，以及哪些詞不能誇大，都會影響最後的樣子。只要求「寫得專業」幾乎等於沒有要求，因為每個人對專業的想像都不一樣。

第五，誰有權說可以繼續？模型可以協助整理與產生草稿，但主題、真實經驗、取捨、修訂與發布責任仍在作者身上。沒有人工核准，前面一個方向錯誤就可能被複製到後面 29 篇。

第六，發現問題時要改哪一層？有時只是某一段寫壞了，有時是整天的範圍重複，也可能是最初的規劃就不成立。若預設所有問題都靠「再生一次」處理，改稿只會變成另一種抽獎。

這些決策也不是彼此獨立。讀者設定會改變技術深度，技術深度會影響每天的內容密度，來源是否可取得又會限制哪些主張能在當天成立。如果沒有先說清楚這些依賴關係，模型每一次看似合理的局部選擇，都可能讓整體方向更難回頭。它不一定立刻產生明顯錯誤，卻會讓作者答不出一個基本問題：這篇為什麼必須出現在這一天，而不是放到系列任何位置都可以？真正的系列需要每篇在順序中有理由，不只是都有編號。

這些不是要把寫作變成填表比賽，而是先把不能交給機率決定的事情挑出來。

先寫再說，錯了再修，不行嗎？

當然可以。對一篇短文而言，先得到草稿再修訂，往往很實用。但把同一做法直接放大到 30 天，就多了一個跨篇問題：後面的文章會依賴前面的定義、順序與承諾。

以下是方法上的推論，不是我已經量測出的實驗結果：當文章彼此相依，較晚才發現的方向錯誤，影響範圍通常不只一篇。這也是為什麼「每篇看起來都能讀」和「合起來是一套可靠的系列」必須分開檢查。

我這次提供給 Skill 的集中 intake，便明確拒絕一次產生 30 篇；它要求先整理 Brief、提出完整規劃、取得人工核准，再一次處理一篇。[^intake] plan-write-blog-series 0.1.0 的核心規則也把「幫我寫 N 天系列」視為訪談與規劃的起點，而不是立即產生 Day 1 的許可；它的 Prompt 範例更直接把收到一句需求後立刻寫第一篇列為錯誤示範。

這個系列也得接受同一套規則

這不是我站在流程外面勸別人要謹慎。我正在用這個 Skill 規劃一套介紹它自己的系列，所以第一個測試就是：它能不能拒絕最誘人的捷徑。

實際流程中，我先把主題、讀者、語氣、來源、限制與交付方式整理成集中 intake。Skill 再據此整理 Brief 與完整 30 天規劃。規劃沒有核准時，Day 1 維持不存在；直到我明確核准目前版本後，才開始產生你現在讀到的草稿。

這只能證明核准閘門在這一次流程中確實擋住了提前撰稿，不能證明整套方法已經解決重複、斷裂或來源不足。那些問題仍要等文章真的一篇篇出現，再用實際結果檢查。要是在 Day 1 就宣布成功，這套系列大概只剩 29 天可以解釋我為什麼太早下結論。

所以今天先停在問題界定：一句「幫我寫 30 篇」提供了數量，沒有提供系列所需的共同目標、篇章分工、內容邊界、證據規則、風格限制、核准責任與修正方式。

下一篇要繼續往下追：即使每一篇單獨看都像文章，整套內容為什麼仍可能重複、斷裂、偷跑結論，最後拼不起來？